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HOSTED SERVICES FOR COLLECTING PAYMENTS FROM AND PROVIDING 
PERSONALIZED CONTENT TO WEB SITE VISITORS 
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Priority Claim 

This application claims the benefit of U.S. Provisional Appl No. 60/244,357, filed 
October 30, 2000, and U.S. Provisional Appl. No. 60/251,437, filed December 5, 2000, 
the disclosures of which are hereby incorporated by reference. 
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Field of the Invention 
The present invention relates to computer-implemented services and user 
interfaces for allowing users to make payments to other users. The invention also relates 
to methods for integrating user-to-user payment services into external web sites, including 
15 but not limited to the web sites of content or service providers. 

Background of the Invention 
Various web-based services have been developed for allowing users to collect 
payments from other users. Examples of such services include Qpass and BillPoint. 
20 These services generally suffer from a number of deficiencies. 

One such deficiency is that the payer typically must complete a significant number 
of setup steps before making a payment to a new payee. As a result, existing services are 
not well suited for allowing payees to collect small or one-time payments from large 
numbers of users. The need to collect such payments may arise, for example, when an 
25 author, musical artist, or other content creator wishes to solicit contributions from 
consumers of downloadable content; or when a charitable organization wishes to solicit 
online donations from the public. 

Another deficiency is that many existing payment services do not provide a simple 
mechanism for web site operators to integrate the collection process into their own web 
30 sites. As a result, prior art payment services are not well suited for small web site 
operators to solicit and collect payments via their own web sites. Such a need may arise, 



for example, when an operator of a web site wishes to receive payments from consumers 
of content hosted by that site. Another deficiency is that existing payment services do not 
provide an adequate mechanism for payees to enlist other web site operators to assist in 
the collection process. 

Prior art payment services also typically lack the ability for payees to efficiently 
provide customized or personalized payment requests to payees. The need to provide 
such requests may arise, for example, when a seller wishes to send a personalized invoice 
to a buyer, or when an individual wishes to request event-related contributions from a 
small group of friends. 

Many payment services also lack a mechanism for external web sites to provide 
content to users according to whether, or the extent to which, such users have made 
voluntary or required payments. In addition, prior payment systems are typically 
incapable of recognizing return customers. 



Summary of the Inventive Features 
The present invention addresses the above and other problems by providing 
various inventive features associated with user-to-user payments. These features may be 
implemented individually, or in an appropriate combination, within a given payment 
service. The payment service may be implemented through a web site of a payment 
service provider. (As used herein, the term "web" refers generally to a navigation 
interface in which users navigate between pages or documents using hyperlinks; and "web 
site" refers generally to a networked server system that supports such a navigational 
interface.) 

One feature of the invention involves the use of customizable, payee-specific pay 
pages for receiving payments. In one embodiment, each user of the service can set up, 
through a set of pay page configuration pages of the service provider site, one or more pay 
pages for receiving payments from other users. The pay pages may be customized by the 
payee with textual and graphical content describing the payee and/or the purpose of the 
pay page. For example, a content creator may create a pay page for collecting honor 
system payments from users who download a work, in which case the pay page may 
describe the content creator and/or the work. The payee may also specify certain 



parameters or behaviors of the pay page, such as minimum and suggested payment 
amounts. Other users may visit the pay page to make credit card or other payments to the 
payee. In one embodiment, users (payers) can set up and enable a 1 -Click™ option and 
thereafter make pay page payments to others with a single action, such as a mouse click. 

Another feature of the invention involves the use of pay page templates to allow 
users to set up customized pay pages for a variety of payment scenarios. Each template 
preferably specifies the display elements and behavior of a pay page. Templates may be 
provided by the service provider for a variety of payment scenarios, including but not 
limited to general purpose payments, honor system payments, tipping, required payments, 
charities, auctions, invoicing, and events. 

Another feature involves the use of pay boxes to allow payers to initiate pay page 
payments from the web sites of the payees and/or third parties. Each pay box serves as a 
link to a corresponding pay page, and may appear as a banner-type graphic image (or 
another type of display object) within the host page. Each instance of a pay box may 
specify one or more pay page parameters that may be preset or passed by URL (Uniform 
Resource Locator), such as a suggested payment amount, pay page color, or a textual 
description. 

In a preferred embodiment, the pay box images are served by the service provider 
site, and are customized for recognized users of the service (e.g., by displaying the user's 
name). Selection of the pay box causes the user's browser to retrieve the corresponding 
pay page (customized according to any parameters passed), or in some embodiments, 
causes the payment to be made as a single-action transaction. Using this feature, web site 
operators can solicit payments on their own web sites while using the service provider to 
collect resulting payments. In addition, the web site operators can customize the 
messaging payers see during and following the payment process. 

Another feature involves serving personalized display objects, such as 
personalized pay box images, within pages of external web sites (web sites that are 
separate and distinct from the service provider site). In one embodiment, a reference to 
the display object is incorporated into the coding of an external web page to cause a 
visitor's browser to request the display object from the service provider site. Upon 
receiving such a request from a recognized user/browser, the service provider site 



personalizes the content of the display object for the particular user, and returns the 
personalized object for display within the web page. The display object may be 
personalized, for example, by displaying one or more of the following types of 
information: (a) the user's name; (b) a portion of the user's credit card number; (c) an 
indication that selection of the object will cause a particular payee to be paid a particular 
amount; (d) personal recommendations of products and/or services; (e) links to related 
content, (f) a payment confirmation message. An important aspect of this feature is that 
the personalized content is provided within external web pages without exposing such 
content - or other personal information of users - to the external web site or its operator. 

Another feature of the invention is an associates program in which users of the 
service can host pay boxes or other payment links of other users - preferably in exchange 
for commissions, bounty payments, or other compensation for resulting referrals. In one 
embodiment, a payee (pay page owner) can associate-enable a pay page and set up one or 
more corresponding pay boxes for others to host. Other users may thereafter install these 
pay boxes on their web sites and earn commissions on referrals that result in payments. 
Using this feature, users can, for example, raise money for (by hosting pay boxes of) their 
favorite charities. In addition, an author, musical artist, or other content creator can allow 
other users to republish a downloadable work under the condition that the content 
creator's pay box is displayed in conjunction with the work. 

Another feature involves rating individual users according to their voluntary 
payment histories (e.g., the frequency with which they make voluntary payments when 
presented the option). These payer ratings may be used to allow content providers 
(typically pay page owners) to provide special treatment, such as access to bonus content, 
to good payers. In one embodiment, the content provider can configure the payment 
service to redirect a visitor's browser to one of multiple destination URLs according to the 
payment history of the visitor. For example, users with poor payment ratings may be 
directed to a standard version of an audio work while users with good ratings are directed 
to an exclusive version of the work. With this method, ratings-based content is provided 
to users without revealing user identities or payment ratings to the content provider. 
Another feature involves redirecting the visitor's browser as described above, but based 
on some user attribute other than payment history. For example, the service provider site 



could select the destination URL based on whether the user has made a particular 
purchase (e.g., users who bought a particular CD can access the bonus tracks associated 
with that CD, while other users can only access samples of such bonus tracks). 

Another feature involves providing payment-based access to content at a 
5 destination URL specified by a pay page owner. In one embodiment, once a visitor 
completes the payment process, the service provider site formats and encrypts a string of 
transaction data according to a particular convention. The transaction data may, for 
example, include one or more of the following: amount of payment, date, time, e-mail 
address of user, and IP address of computer making request. The service provider site 

10 passes the encrypted string to the destination site - preferably with the destination URL 
via a redirect message. The destination site decrypts and validates the string, and provides 
or denies access to the associated content according to the validity of the transaction data. 
In another embodiment, the payer is given the URL in plain text following payment. 

Another feature involves a service for users to send customized payment requests 

15 to other users. To send a payment request, the payee preferably creates or selects an 

existing pay page and then specifies how the page should be displayed to the payer. For 
example, an auction seller may specify the item name, winning bid, tax, and shipping 
amounts to be displayed within the pay page. The service then sends an email to the 
payment request recipient(s) containing a link to the pay page. The URL portion of this 

20 link preferably includes parameters specifying how the page should be displayed. This 
feature may be used, for example, for sending custom invoices to purchasers, and for 
collecting membership dues and event-related contributions from small groups of users. 

Another service feature allows payees to display a real time payment counter on 
their pay pages. The counter may, for example, be displayed as a goal chart showing the 

25 number or amount of payments received since inception, together with a payee-specified 
goal. This feature may be used on pay pages of charities, for example, to display a real 
time total of the amount received during a fundraising event. Further, creators of 
downloadable works may use the feature to indicate the number of visitors that have made 
honor system payments for a particular work. 

30 Another feature involves the provision of single-action payment links within 

external web pages to allow users to access, and make payments for, items of content. For 
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example, a content provider site may include a payment link for allowing users to access 
and pay for a particular article. When a recognized 1 -Click user selects this link, the SP 
site charges the account of the visitor (typically a small payment in the range of 5 to 50 
cents), and redirects the visitor's browser to the content provider page containing the 
5 content. This content page may include one or more display objects served by the service 
provider site, such as a bar displaying a payment confirmation message. Multiple 
payments made by the same user may be aggregated for purposes of charging the user's 
credit card. The content page may also include links to other services provided by the 
service provider site, such as an "unpay" button or a button for adding the content item to 
10 a personal library. 

The various features of the invention may be implemented within conventional 
web sites that are based on HTML (Hypertext Markup Language), and may also be 
implemented within web sites that use HDML (Handheld Device Markup Language), 
XML (Extensible Markup Language), and other coding conventions. 

15 

Brief Description of the Drawings 
A computer-implemented payment service that embodies the above and other 
inventive features will now be described with reference to the following drawings: 

Figure 1 illustrates an overall process flow through which users register with the 
20 payment service, manage pay pages, and perform various related actions using a service 

provider web site. 

Figure 2 illustrates the basic web site components used to implement the payment 
service. 

Figure 3 illustrates the process through which the service provider site displays 
25 pay pages and processes pay page transactions. 

Figure 4 illustrates an example pay page. 

Figures 5-12 illustrate example web pages showing how users manage pay pages 
and pay boxes through the service provider site. 

Figures 13-16 illustrate example web pages showing how users can locate and 
30 install pay boxes of other users to become pay page associates. 
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Figures 17-19 are screen displays illustrating a feature through which users can 
request payments from other users via customized versions of existing pay pages. 

Figure 20 illustrates a sequence of events that occur when a user requests a web 
page containing a pay box. 

Figure 21 illustrates a method by which the service redirects users to outside 
content (typically of the pay page owner) based on the voluntary-payment history of the 
visitor. 

Figure 22 illustrates a method by which 1-Click users may complete payment 
transactions directly from externally-hosted pay boxes. 

Figures 23-25 are hypothetical screen displays showing how web pages of external 
web sites may be augmented with (a) links to services provided by the service provider 
site, and (b) personalized content served by the service provider site. 

Figure 26 illustrates an instruction page for adding payment links and customer 
review modules to pages of external web sites. 

Figures 27 and 28 illustrate a payment link generation tool of the service provider 

site. 



Detailed Descri ption of the P referred Embodiment 
A computer-implemented payment service that embodies the various inventive 
features will now be described with reference to the drawings. The service is hosted by a 
service provider site (also referred to generally as "the system"), which comprises an 
HTML-based World Wide Web site in the illustrated embodiment. As will be recognized, 
the service and its various features may also be implemented within other types of web 
sites and server systems, including but not limited to systems that provide wireless 
browsing capabilities. The various service functions described herein are preferably 
implemented within software executed by one or more general-purpose computers, but 
could be implemented using other types of computing devices. 

As will be apparent, the various inventive features of the service may be 
implemented differently than described herein. Further, the service may be implemented 
with only a subset of the disclosed features, and/or with additional features that are not 



disclosed. The following description is thus intended to illustrate, and not limit, the 
invention. The scope of the invention is defined by the appended claims. 

The description of the payment service is arranged within the following sections 
and subsections: 

5 

L Terminology 

II. Overview 

A. General Process Flow 

B. System Components 

10 C . Pay Page Transaction Processing 

III. Example Pages and Page Flows 

A. Management of Pay Pages and Pay Boxes 

B . Associate Hosting of Pay Boxes 

C. Sending a Payment Request 
1 5 IV. Pay Page Templates and Parameters 

V. Pay Boxes and SP-Generated Display Objects 

VI. Pay Box Tracking and Feedback Reports 

VIL Controlled Access to Content Based on Payment History or Other User 
Attribute 

20 VIII. Payment-Based Access to Content 

IX. Display of Payment Counter Data within Pay Pages 

X. 1 -Click Payments from External Sites 
XL Content Distribution Models 

XII. Integration of Payment Service with External Content Provider Site 
25 XIII. Payer Preferences for Treatment on External Sites 

L Terminology 

The following terms will be used throughout the description of the payment 



service: 



30 
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Pay page - A custom page or screen through which an associated user (the "payee" or pay 
page "owner") can receive payments from other users. Typically, a pay page includes 
information about its owner. Pay pages are persistent, meaning that a given pay page may 
be used to receive many separate payments over time (from the same or different users). 
In one embodiment, payees can create pay pages for a variety of different types of 
payment scenarios (using corresponding pay page templates), such as general-purpose 
payments, honor system payments, charitable donations, and invoice payments. 

Service provider or "SP" - Generally, the business entity (or combination of related 
entities) that operates the payment service. 

Service provider site (or SP site) - A networked computer system, such as a web-based 
server system, that implements the payment service. This system may be accessible 
through a single or multiple Internet domain names, and may include computers that are 
geographically remote from one another. In the sample screen displays, the SP site 
includes the amazon.com web site. In one embodiment, the SP site also hosts or is linked 
to other types of e-commerce services, such as retail sales, music download, and online 
auction services. Sites or pages that are separate and distinct from the SP site are referred 
to as being "external." In the illustrated embodiments, it may be assumed that all external 
sites are hosted by computers that are outside the control of the SP, and that such sites are 
controlled by business entitles other than the SP. 

Pay box - A display object that may be incorporated into a page to provide functionality 
for viewers of that page to initiate payments to a pre-specified recipient. In the preferred 
embodiment, each pay box includes a graphical image served by the SP site and provides 
a link to a corresponding pay page. In one implementation, pay boxes that point to a 
particular pay page may be installed within a web site of the pay page owner ("second 
party sites") and/or web sites of third parties ("third party sites" or "associate sites"). Pay 
boxes may optionally specify pay page parameters, such as a suggested payment amount. 



Pay box graphic (or "pay box image") - The graphical image portion of a pay box (e.g., a 
GIF or JPEG file). When a user views a page having a pay box installed therein, the user's 
browser requests the pay page graphic from the service provider (SP) site. In one 
embodiment, if the user is recognized by the SP site this graphic is customized for the 
particular user (e.g., by incorporating the user's name into the graphic). The graphic may, 
but need not, be similar in size and appearance to conventional banner ad graphics. A 
textual link, button, icon, or another type of content (Flash, Shockwave, etc.), may 
alternatively be used. 

Associate - A web site owner or operator that hosts (displays) a pay box or other link to a 
pay page of another user, potentially in exchange for commissions or other compensation 
for resulting referrals. For example, a music download site may host pay boxes of the 
associated artists to allow users to make voluntary or mandatory payments to the artists; 
the operator of the music download site (associate) may receive commissions on such 
payments. The use of third party web sites to display pay boxes is also referred to as "pay 
box syndication." 

Honor system payments - Payments in which the visitor is asked to pay a particular 
amount in return for accessing content. For example, users may be asked, via a pay box 
hosted on a music download site, to pay $1 for each MP3 file downloaded. The content 
may also be in the form of a computer-implemented service (e.g., locating the best price 
for an item). Voluntary payments for accessing content may also be referred to generally 
as "tips." 

1 -Click - A service which allows a customer to complete a transaction with a single 
action, such as a single mouse click, using pre-specified information. One 
implementation of such a service is described in U.S. Patent No. 5,960,41 1, the disclosure 
of which is hereby incorporated by reference. 
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L Overview 

The payment service preferably provides functionality for users to receive 
payments from other users via payee-customized pay pages. In one embodiment, once a 
user has set up an account with the SP, a default pay page is automatically created for that 
5 user. In another embodiment, pay pages exist only for those users who have actively 

created a pay page. In either case, each user can preferably have more than one pay page. 
For example, a musical group may create a separate pay page for each work it has posted 
in digital form (see Figure 7), and may use these pay pages to collect voluntary payments 
(tips or honor system payments) from users that download such works. Further, an 

1 0 individual may create one pay page for personal use and another for business use. 

In a preferred embodiment, each pay page is based on a template that specifies the 
layout and the behavior of the pay page. Each template contains default values that can be 
overridden by the pay page owner during the pay page setup process. Each pay page 
preferably includes the following "required" information fields or values: (1) a title, (2) an 

15 identifier of the pay page "owner" or "payee " (3) a description, and (4) an amount, which 

can typically be modified by the payer. Additional fields and options may be defined by a 
particular template. Different templates may be provided for different types of 
organizations, such as charitable organizations, authors, musical artists, other content 
providers, and individuals. Further, templates may be provided for specific types of pay 

20 page uses, such as tipping, honor system payments, invoicing, auctions, membership dues, 
rebate requests, and payments required for access to content. The types of elements that 
may be included within a template in one embodiment are described below in section IV 
("Pay Page Templates and Parameters"). 

Each pay page preferably has a unique URL (Uniform Resource Locator). The 

15 URLs of the default pages (if used) are preferably based on a naming convention in which 

the user's email address is the only variable (e.g., www.paypages.com/<email 
address>.htm). This allows users to easily locate the default pay pages of other users. An 
SP-assigned or user-selected nickname may be used in place of the email address. Other 
types of pay pages may be given encoded URLs that are relatively difficult to identify 

50 through trial and error. As discussed below, the service may support a variety of methods 

for locating and accessing pay pages, including pay boxes and a search engine. 
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In addition to the payee-specific pay pages, the service may provide a generic 
"send money" page for sending money to payer-specified recipients. 

Although the web sties and pages in the illustrated embodiments use HTML 
(Hypertext Markup Language) coding, it will be apparent to those skilled in the art that 
5 other markup languages could be used. For example, the inventive features could be 
implemented using web sites and web pages that use HDML (Handheld Device Markup 
Language), XML (Extensible Markup Language), or another appropriate markup 
language. In addition, although the use of personal pay pages provides important benefits, 
it will be recognized that many of the features of the invention can be implemented 
10 without requiring payees to have pay pages. 



A. General Process Flow (Figure 1) 

Figure 1 illustrates the basic process flow through which users register with the 
service, manage pay pages, and perform various related actions. Each state within Figure 

15 1 corresponds generally to one or more pages of the SP web site. As indicated by the 

figure numbers listed in Figure 1, examples of some of these web pages are included in 
subsequent drawings. The process by which users make payments via pay pages is shown 
in a separate drawing (Figure 3). 

As depicted by the "log-in" state 30, users initially enter the payment service by 

20 logging-in with a pre-selected username and password (or other authentication 
information). New users must initially register with the service (state 32) before they can 
make or receive payments via pay pages. During the registration process, the user enters 
various account information such as a name, credit card number, password, and email 
address. During or following the registration process, the user can also preferably enter 

25 settings for, and enable, the system's 1-Click™ service. As discussed below, when the 1- 
Click service is enabled, the user can make pay page payments with a single mouse click 
or other single selection action. In one embodiment, users can also make 1 -Click 
payments directly from pay boxes hosted on external web sites. During or following the 
registration process, the SP site stores a cookie on the user's computer to permit 

30 subsequent identification of the user. 
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As illustrated by state 34, the user may also optionally link the account with the 
SP to an existing checking account. The bank routing number associated with the 
checking account may be determined automatically, based on information entered by the 
user from the face of a check, using the process described in U.S. Appl. No. 09/517,563, 
5 filed March 2, 2000, the disclosure of which is hereby incorporated by reference. Once 
the pay page account has been linked to a checking account, the user may initiate transfers 
of funds between the two accounts (state 60). 

As depicted by state 36, the service may include a main page (see Figure 5) or 
other area from which users can initiate various actions. The main page preferably 

10 displays a listing of the user's pay pages (if any), and allows the user to select a particular 

pay page with which to perform an action. As illustrated by state 40, the user can create a 
new pay page, and can an edit, view, or delete an existing pay page (see example page 
flow in Figures 5-7, discussed in section III-A below). 

As depicted by state 42, the user may also create, edit and delete pay boxes for a 

15 particular pay page (see example page flow in Figures 8-11, discussed in section III-A 

below). Once a pay box has been created, the pay page owner (and in some embodiments, 
other users) can "install" that pay box within one or more external web pages to provide a 
link to the corresponding pay page. To facilitate this process, the service automatically 
generates a sequence of HTML (Hypertext Markup Language) coding to be added to the 

20 host web page (see Figures 10 and 16, discussed below). This HTML coding includes a 
reference to the pay box image (hosted by the SP site), such that the image is 
automatically requested from the SP site when the page is displayed by a browser. The 
coding may alternatively be generated according to another markup language or link 
coding convention. For example, in a wireless environment, the appropriate HDML 

25 (Handheld Device Markup Language) coding may be generated. Further, the payment 

service may generate coding for installing other types of links (e.g., textual) to pay pages. 

One particular application for the pay box feature is to provide a mechanism for 
compensating creators of digital content. For example, a content creator such as a musical 
group, author, or web site operator could install a pay box on its own (second party) web 

30 site to solicit voluntary or mandatory payments from users. Users who access the content 
can then click through the pay box to make voluntary or required payments to the content 
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creator. The amount of this payment (e.g., $1 per download) may be suggested by the pay 
box, in which case this amount is preferably displayed within the pay page when the user 
clicks through (as described below). Where the payments are "required/' an appropriate 
mechanism may be used to prevent access to the content until the user has paid (see, for 
5 example, section VIII titled "Payment-Based Access to Content"). 

One variation of this model is for the SP itself to provide a forum for content 
creators to post their works in a downloadable form. The posted works could then be 
displayed (e.g., on product detail pages) in conjunction with pay boxes for soliciting 
voluntary (or mandatory) payments. With this model, any user (regardless of whether it 

10 operates a web site) could post a work on the SP site and use the payment service to 

collect payments from users. For example, a relatively unknown musical group could 
post a song or album in MP3 format together with a pay box requesting a voluntary 
payment of $1 per download. 

In one embodiment of the payment service, during the pay page creation or editing 

1 5 process (state 40) the user may "associate-enable" a particular pay page. Once a pay page 

has been associate-enabled, other users may install one or more of that pay page's pay 
boxes within their own web pages - optionally in exchange for commissions or other 
compensation for resulting referrals. For example, a charitable organization such as the 
Red Cross may associate-enable its pay page and create one or more pay boxes for that 

20 page. Other users (associates) may then install these pay boxes on their own web sites to 

provide a mechanism for others to locate the Red Cross pay page. When a user (a) 
follows (clicks through) such a pay box and then makes a payment on the corresponding 
pay page, or (b) where applicable, makes a 1 -Click payment from the pay box, the 
associate who generated the referral may be given a portion of that payment. 

25 To become a pay page associate, the user initially searches for or otherwise 

navigates to a desired associate-enabled pay page (state 46). A search engine may be 
provided for this purpose. The user then selects a corresponding pay box (or optionally 
another type of link to a pay page), and installs the pay box on one or more third party 
sites (state 48). This process is illustrated by the example page flow of Figures 13-16, 

30 discussed in section III-B below. 
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One particular application for the associate feature is to provide a mechanism for 
compensating distributors of digital content. A third party (associate) distributor of digital 
content (e.g., a music or e-book download site) could display the pay boxes of artists, 
authors or other content creators together with the associated content. When users click 
through such pay boxes and make voluntary payments to the content creators, the third 
party associate may be given a portion of each payment as compensation for distributing 
the content. Another specific application is to allow web site operators to raise money for 
their favorite charities while receiving commissions. 

As illustrated by state 52, the system may also permit users to generate and send 
payment requests to other users. To initiate a payment request, the payee-user specifies 
the email address(es) of one or more recipients, and enters pay page customization data 
specifying how the payee's pay page should be displayed to such recipients. This 
customization data may include, for example, a requested payment amount and an 
associated textual description. The system responds to initiation of the payment request 
by sending an email to each recipient with a URL-encoded link to the pay page. The URL 
portion of this link includes parameters that are used by the SP web site to determine how 
to display the page. This feature of the system may be used, for example, to send 
customized invoices to other users. Other example applications for this feature are 
described below in section III-C ("Sending a Payment Request"). 

As depicted by state 54, the service may also provide an option to set up an 
automated payment request or a recurring payment request. An automated payment 
request may be used, for example, by an online auction seller to automatically send 
invoices (links to customized pay pages) to winning bidders. Such a pay page may 
automatically be populated with the picture and description of the auction item (as 
displayed within the corresponding auction page) and the dollar amount of the winning 
bid. A recurring payment request may be used to collect any type of recurring payment, 
such as subscription fees or group membership fees. 

Finally, as depicted generally by states 56-60, the service may provide various 
account management pages. From these pages, the user may perform such actions as 
viewing pay page transactions (both payee and payer), transferring funds into and out of 
the account, and updating a user profile. The service may also generate, send and retain 



-15- 



transaction receipts, and may provide reporting for tax purposes (e.g., for payments to 
charitable organizations). 

B. System Components fFigure 2) 
5 Figure 2 illustrates a set of components that may be used to implement the 

payment service on the SP site 66. The system includes a web server 68 which accesses a 
content database 70 and a user accounts database 72. The system may also include 
databases for storing other types of information, such as a products database and an 
auction database (not shown). 

10 The web server 68 includes a pay pages application 76 which embodies the 

various pay page related functions described herein. The pay pages application includes 
or makes use of modules for performing some or all of the following tasks or services: (a) 
identification of return visitors to the SP site using cookies, (b) generation of customized 
pay pages and pay boxes according to settings specified by payees, (c) display of the pay 

15 pages to visitors, customized according to any parameters passed with page request and 

customized with visitor names/l-Click settings, (d) processing of payment transactions, 
including tracking and crediting associates for referrals and sending "thank you" emails to 
payers, (e) generation of HTML or other coding for installing pay boxes, or other links to 
pay pages, within external pages, (f) user browsing of associate-enabled pay pages and 

20 their associated pay boxes, (g) generation of payment requests, and (h) user viewing and 

updating of pay page account information. Each module preferably includes executable 
code, and where applicable, includes web pages for interacting with users. Other 
functions and services that may be implemented by the pay pages application are 
described below. 

25 As illustrated, web server 68 communicates with an image server 77 that 

dynamically generates and serves pay box graphics (and possibly other types of images) 
for display within external web pages. Another type of object server, such as a server of 
animation objects or other executable display objects, could alternatively be used. In one 
embodiment, the pay pages application 76 and the image server 77 recognize different 

30 browser capabilities (HDML, wireless, WAP, etc.) and device types, and select the pay 
pages and pay boxes to display accordingly. 
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The web server may also include applications 78 for implementing other types of 
services such as a retail sales service and one or more person-to-person sales services. 
The various applications 76, 78 may share code modules for implementing common tasks 
such as registration, user authentication, and credit card processing. 

The web server also preferably communicates with a search engine 80 for 
searching the various areas of the site. Using this search engine, users can search for pay 
pages of other users based on user name and other criteria. As mentioned above and 
illustrated in Figure 12, users can run searches specifically for pay pages that are 
associate-enabled. 

As depicted in Figure 2, the content database 70 includes the pay pages created by 
users, and includes pay page templates that may be used to generate page pages. As 
mentioned above, different templates may be provided for different payment-related 
scenarios. The templates are preferably created by the service provider, although the 
service could provide functionality for payees to create their own templates. The content 
database also includes web pages and templates for the various other areas of the site. 

The content database 70 may also include the descriptions of pay box styles made 
available by the SP, and specifications of pay boxes that have been defined by pay page 
owners. The specification of a pay box may indicate, for example, the pay box style, 
color, suggested payment amount, textual message, and greeting format (see Figures 8 
and 9). Some or all of these pay box parameters may alternatively be encoded within pay 
box identifiers passed by URL. As described below, the image server 77 uses the pay box 
specifications to dynamically generate and serve pay box graphics (e.g., GIF images) to 
user computers 84. The pay box graphic may also be customized to include the name and 
other information about the visitor, if known. 

In embodiments in which the SP site allows users to post and receive voluntary 
payments for digital works (as described above), the content database may also include 
copies of such works (not shown). These works may be located using the site's search 
engine or any other suitable navigation interface. 

As further illustrated in Figure 2, the user accounts database 72 stores account- 
specific information about users of the site. For each user, this information preferably 
includes a user profile (name, credit card number, 1 -Click settings, etc.), an account 
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balance, a history of transactions (including incoming and outgoing pay page payments), 
and information about any pay page associate relationships the user has created. 

C. Pay Page Transaction Processing (Figures 3 and 4") 

Figure 3 illustrates the basic process by which the SP web site 66 displays pay 
pages, and processes pay page transactions, via the pay pages application 76. As depicted 
by block 90, the web site initially receives a URL request from a user/computer 84 for a 
particular pay page. If the URL request resulted from user selection of pay box, the URL 
may include one or more parameters that override the default values of the pay page. For 
example, if the pay box specifies a suggested payment amount, this amount is passed via 
the URL and overrides the default amount displayed within the pay page. Additional 
details of how parameters may be used are described below in section IV ("Pay Page 
Templates and Parameters.") If the URL request resulted from selection of a pay box 
hosted by an associate, the URL also preferably includes a unique identifier of the 
associate. 

If the URL request is from an existing user of the service, the request typically 
includes a cookie that is used by the system to identify the user. The use of cookies for 
this purpose is well known in the art. 

As depicted by block 92 of Figure 3, the web site responds to the URL request by 
generating and returning (displaying) the pay page. An example pay page as seen by the 
user is shown in Figure 4. As illustrated, the pay page preferably includes a default or 
owner-assigned title 92A, a graphic image (logo or photo) 92B uploaded by the pay page 
owner 92B, and a memo or description 92C entered by the pay page owner. In addition, 
the pay page includes a greeting message 92D that identifies the visitor by name (if 
known). If the visitor's identity is unknown, a default message may be used such as 
"Please sign in ." 

As further illustrated by Figure 4, the pay page also includes an "amount" field 
92E in which the visitor can enter a payment amount, and a payment button 92F or other 
link for allowing the visitor to initiate the payment process. In the illustrated example, a 
suggested payment amount of $2 appears in the amount field 92E. If the visitor is known 
and has the 1 -Click service enabled (as in the Figure 4 example), the payment button 92F 
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is preferably configured and labeled as a 1 -Click button that can be selected to complete 
the payment transaction. If, on the other hand, the visitor either (a) is unknown, or (b) is 
known and does not have the 1 -Click service enabled, the payment button 92F includes a 
message such as "Pay Now! (select your credit card)." 

As depicted by the "1 -Click" path in Figure 3, if the visitor selects a 1 -Click 
version of the payment link 92C, the system 66 executes the transaction (preferably within 
a predefined period of time) without requiring any further user action. In addition, the 
system displays a thank you page (block 98) or redirects the user to an owner-specified 
page (typically a "thank you" page of the owner's external web site). No additional user 
action is needed to complete the payment transaction at this point. If, on the other hand, 
the visitor initiates payment via a non-1 -Click link, the visitor may be required to log-in 
or register and select a credit card before the transaction is executed (blocks 94 and 96). 

Although credit cards are used in the illustrated embodiment, any appropriate 
method for transferring funds between users can be used. In addition, it should be 
understood throughout the various embodiments described herein that the payer's credit 
card need not actually be charged at the time of the transaction. For example, in 
embodiments in which users typically make frequent small payments (e.g., less than $1) 
for accessing articles or other content, the SP site may aggregate a number of payments 
for purposes of charging the user's credit card. 

As depicted by block 100, if the visitor was referred to the pay page from a pay 
box displayed within an associate web site, the system may credit the account of the 
associate-user with a commission. The system could additionally or alternatively be 
configured to credit the associate's account with a bounty payment (e.g., for each referred 
user who sets up an account with the SP). Examples of methods that may be used to track 
referrals from associate web sites and determine associate commissions are described in 
U.S. Patent No. 6,029,141, the disclosure of which is hereby incorporated by reference. 
As depicted by block 102, the SP may extract a transaction fee before crediting the 
remainder of the payment amount to the payee's account. 

As described below in section X ("1 -Click Payments from External Sites"), the 
above-described process may be varied to allow 1 -Click visitors to complete the 
transaction directly from an externally-hosted pay box, such as by simply clicking on the 
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pay box. In such instances, the SP site responds to selection of the pay box by 
immediately redirecting the visitor's browser to an external URL pre-specified by the pay 
page owner (or in some embodiments, the associate). Thus, the transaction is completed 
without requiring the visitor to view the pay page. 

The process shown in Figure 3 may also include appropriate error handling tasks 
(not show) for processing invalid pay page parameters, invalid pay page entries (e.g., 
payment amount less than minimum payment amount), and other error conditions. 

III. Example Pages and Page Flows 

Figure 5 illustrates an example "main page" of the payment service. This page 
displays the user's pay page account balance, and lists the pay pages that are currently 
active within the account. The page also provides links for the user to perform the 
following types of actions with respect to a selected pay page: edit page, delete page, view 
page, manage page's pay boxes, and send payment request. The option to send payment 
requests may be omitted, or may be provided only for certain types of pay pages (e.g., the 
user's default pay page). The main page also provides links for the user to create a new 
pay page, become a pay page associate, and access other areas of the site. 

A - Management of Pay Pages and Pay Boxes (Figures 6-12^ 

The basic process for creating and managing pay pages and associated pay boxes 
will now be described with reference to Figures 6-11. In this example flow, it is assumed 
that all pay pages are created using the same template. Where different templates exist for 
different types of pay pages, a user wishing to create a new pay page may initially be 
prompted to select the pay page type. 

Figure 6 illustrates the "step one" page of the pay page management process. This 
page may be accessed by selecting the "Create a New PayPage" button, or one of the 
"edit" buttons, on the main page (Figure 5). This "step one" page summarizes the six 
categories of pay page settings that can be customized, and provides respective "edit" 
buttons for allowing the user to modify the default settings. 

The first category of settings is the messaging associated with the pay page. The 
messaging includes a pay page description to appear on the pay page, a thank-you 
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message to be displayed to a payer following payment, and a thank you message to be 
sent by email to the payer. The pay page owner may also be given the option to upload an 
audio or video clip to be played within the pay page. 

The second category is the title and color scheme of the pay page. The color 
scheme may, for example, be selected to be similar to that of the owner's referring site. 

The third category is an optional image to be displayed within the pay page. This 
may be used, for example, to display a picture of the pay page owner, or to display an 
image associated with the downloadable content to which the pay page corresponds. 

The fourth category is the payment settings of the pay page. These settings 
include a default payment amount (the amount transferred if the payer does not modify 
the amount field) and a minimum payment amount. 

The fifth category is the advanced settings for the pay page. By editing the 
advanced settings, the user can specify whether the page is to be associate-enabled, and if 
so, the commission percentage to be paid for referrals. In addition, the user can specify a 
location and an email address to be displayed within the pay page, and can specify the 
URL of a thank you page to be displayed upon completion of the payment process. 

The sixth category involves the use of an optional payment counter. This feature 
can be used to display an optional chart on the pay page. When this feature is enabled, the 
pay page includes a real time counter indicating an amount received, and/or a number of 
payments received, via the pay page or an owner-specified set of co-owned pay pages. 
The counter may optionally be displayed as a goal chart indicating the payment total 
relative to an owner-specified goal. The payment counter feature may be used, for 
example, by charities to display real time fundraising data. An example implementation 
of this feature is described below in section IX titled "Display of Payment Counter Data 
within Pay Pages." 

When the user finishes customizing the pay page settings, the user can select a 
"continue" button to access the "step two" page (Figure 7). In step two, the user previews 
the pay page, and can either go back to make additional changes or proceed to step 3. 

In step three (Figure 8), the user can select a pay box style to use with the pay 
page. The user can alternatively return to the main page (Figure 5) by selecting the 
"Manage PayPages" link. In the illustrated example, each style corresponds to a 
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particular pay box size. Although rectangular pay boxes are used in this example, pay 
boxes having other configurations may be used. 

In step four (Figure 9), the user can create a pay box having the previously 
selected style. Specifically, the user can specify a greeting and message to be displayed in 
the pay box, and can choose a pay box border color. In addition, the user can specify a 
suggested payment amount (e.g. $1) for use with the pay box. 

Preferably, when a suggested amount is specified, this amount is passed by URL 
as a parameter, and is displayed on the pay page when a user accesses the pay page 
through this pay box. Different pay boxes for the same pay page may have different 
suggested payment amounts (or other pay page parameters). Although only one type of 
pay page parameter (payment amount) is shown in Figure 9, the pay box creator may be 
prompted to specify other types of parameters, such as pay page display color, other 
textual fields, etc. In this manner, the pay page can be customized (displayed) differently 
for different pay boxes. The use of parameters to specify pay page display attributes is 
described in section IV ("Pay Page Templates and Parameters"). When the user selects 
the "continue" button to proceed to step five, the pay box settings are stored in the content 
database 70 for subsequent use. 

In step five (Figure 10), the pay box is displayed to the user together with the 
HTML code for installing the pay box on a web site. The pay page owner can install the 
pay box within any number of web pages by copying the block of HTML code into the 
HTML coding of such web pages. Advanced users can also manually append additional 
parameters to the pay page URL to control other display attributes of the pay page. 

As illustrated in Figure 10, the HTML code includes a reference to the pay box 
graphic served by the SP site. Thus, when a user/browser retrieves the HTML document 
in which the pay box is installed, the browser automatically requests the pay box graphic 
from the SP site. If the request includes a cookie that allows the SP site to identify the 
user, the SP site preferably incorporates the identified user's name into the pay box 
graphic as shown. Selection of the "continue" button of the "step five" page returns the 
user to the main page (Figure 5). 

As illustrated in Figure 5, the user can also view and manage the pay boxes 
associated with a particular pay page by selecting the corresponding link titled "Manage 
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this PayPage's pay boxes." Figure 11 illustrates an example of the "manage pay boxes" 
page that appears when this link is selected. 

Although the pay boxes shown in the Figures 8-1 1 vary in size and contain textual 
content, "standard" pay boxes without any textual content may alternatively be used. For 
example, as described below, standard buttons or icons may be used in which the payment 
amount is represented by a particular color (e.g., green, blue and red payment buttons 
represent payments of 5 cents, 10 cents, and 25 cents, respectively). This may be useful, 
for example, where the pay boxes are used to make small, frequent, 1 -Click or other 
payments from external content provider sites (see section X, "1 -Click Payments from 
External Sites"). 

Figure 12 illustrates a simplified web form that may be used to create pay pages. 
In this example, the pay page creator can specify a referral commission (percentage) for 
paying associates. 



B. Associate Hostine of Pay Boxes fFigures 13-1 6) 

The process of enrolling as a pay page associate involves locating an associate- 
enabled pay page, selecting a pay box associated with that pay page, and then installing 
the pay box within one or more web pages. Thereafter, whenever a visitor to such a web 
page clicks on the pay box and makes a payment, the associate typically receives a 
commission. A given pay page may have an unlimited number of associates. In addition, 
a given user may become an associate of multiple different pay pages and pay page 
owners. 

Figure 13 illustrates a page that may be used to search for associate-enabled pay 
pages. As illustrated, users can search for pay pages based on one or more of the 
following: name/description, city, and state. Any of a variety of other navigation tools 
may be provided for locating associate-enabled pay pages, including browse trees in 
which the pay pages are arranged by category. 

Figure 14 illustrates an example search results page for the search "name or 
description = Animal Society." This page lists the matching pay pages, and provides 
links for viewing the pay pages and their associated pay boxes. Where multiple 
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commission rates are supported, the page may also indicate the commission percentages 
offered by the owners. 

Figure 15 illustrates an example page listing the pay boxes that have been defined 
for the pay page titled "The Animal Society in Seattle, WA." From this page, the user can 
select the style of the pay box to host. Upon selection of the "continue" button, the SP 
site returns a page with the selected pay box style and a sequence of HTML for installing 
the pay box (Figure 16). This HTML sequence is similar in form to the sequence in 
Figure 10, but includes a unique identifier of the associate (assigned by the pay pages 
application 76 and stored in the accounts database 72) within the URL of the pay box 
graphic. As described above with reference to Figure 3, the pay pages application uses 
this identifier to determine the identity of the referring associate and to keep track of 
referral events. 

In some embodiments, the associate may be given the option (not illustrated) to 
define pay page parameters to be used with the associate-hosted instance of the pay box. 
For example, the associate may be permitted to enter a suggested payment amount, an 
associate name or logo for co-branding the pay page, and/or a post-payment destination 
URL. Some or all of these parameters may automatically override the owner-specified 
parameters associated with the pay box. 

C. Sending a Payment Request (Figures 1 7-1 9) 

As mentioned above, the payment service may also provide a service for users to 
send payment requests to other users via customized pay pages. The user preferably 
initiates a payment request by selecting a pay page to be used for the request (e.g., by 
selecting a "send payment request" link as shown in Figure 5). Alternatively, the user 
could be prompted to select from a list of predefined payment request templates, in which 
case a new pay page may be created to process the payment request. 

Figure 17 illustrates an example page that may be used to send a payment request 
using a selected pay page. From this page, the user can enter (or select from a personal 
address book) the names and email addresses of the payers (payment request recipients). 
In one embodiment, new payers are automatically added to the user's personal address 
book. 



-24- 



As further illustrated in Figure 17, the user may also enter an optional description 
and an optional payment amount, both of which override the description and payment 
amount (if any) defined within the pay page. Depending upon the type (template) of the 
pay page used, the user may also be prompted to specify other pay page fields and options 
(not shown). For example, if the payment request corresponds to a pay page for auction 
invoices, the user (payee) may also be prompted to enter the name of the winning bidder 
and the details of the transaction (item number, winning bid, shipping costs, etc). 

In the illustrated embodiment, the "send payment request" page also includes a 
link 108 to a page (not shown) for making the payment request automatic or recurring. 
For example, the user can specify that the payment request should be re-sent each month, 
or should be sent automatically to a winning bidder upon completion of an auction. 

When the user selects the "send payment request" link, the system 66 stores the 
submitted form data and sends email messages to each of the listed payers. As illustrated 
in Figure 18, this email message includes a hyperlink 1 10 to the customized version of the 
selected pay page. The URL portion of this hyperlink (not shown) points to the pay page, 
and includes one or more parameters for customizing the pay page. These parameters 
may include the values entered by the pay page owner (e.g., the payment amount), and/or 
may include identifiers for allowing the pay pages application 76 to look up such values 
from a table. The use of URLs to pass pay page parameters is discussed separately below 
in section IV ("Pay Page Templates and Parameters"). When a payment request recipient 
selects the hyperlink, the system 66 returns the customized pay page as discussed above 
with reference to Figure 3. 

Figure 19 illustrates an example pay page used to request donations associated 
with an event. In this example, the payer is recognized by the system and has the 1-Click 
service disabled. As mentioned above, pay pages used for other types of payment request 
scenarios may include other types of fields. For example, a pay page used for requesting 
payment from the winning bidder in an auction may include fields for the item number, 
winning bid amount, shipping charges, taxes, and a shipping address; these fields may be 
populated automatically by the pay pages application 76 in response to successful 
completion of an auction, or may be filled in by the seller. 
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IV. Pay Page Templates and Parameters 

Pay page templates specify both the "look and feel" and the behavior of the pay 
pages. In the preferred embodiment, every pay page is based on a template. As 
mentioned above, templates may be provided by the SP for each of a variety of payment 
scenarios, such as charitable donations, events, invoices, auctions, rebate requests, and 
downloads of digital content. 

Each template preferably specifies the elements that appear on a pay page. Table 
1 below lists and describes the elements that may be included in a template in one 
embodiment of the invention. The column labeled "type or size" in Table 1 indicates the 
type or size of the element. The "display on template" column indicates whether the 
owner sees the element during the pay page creation/editing process (if set to NO, the 
element takes on the default value specified by the SP). The "edit by creator" column 
specifies whether the owner/creator can modify the value associated with the element 
during pay page creation. The "edit by payer" column indicates whether the payer (pay 
page visitor) can modify the value. The "pass in URL" column specifies whether the 
element's value can be passed as a parameter with the pay page URL. 



Element 


Description 


Type or 
Size 


Display on 
Template 


Edit by 
Creator 


Edit by 
Payer 


Pass in 
URL 


amount 


the amount to be paid 


currency 


Y 


Y 


Y 


Y 


memo 


note passed with payment 


80 


Y 


Y 


Y 


Y 


anonymous 


hide payer's email address from 


Boolean 


Y 


Y 


Y 


N 




payee 










image 


url pointer to page image 


120 


Y 


Y 


N 


N 


page title 


Title of the page displayed to the 
customer and payee 


60 


Y 


Y 


N 


N 


page name 


name of page, used in URLs 


16 


Y 


Y 


N 


N 


description 


User description of themselves, 
PayPage 


2000 


Y 


Y 


N 


N 


bordercolor 


Color used for PayPage border 




Y 


Y 


N 


Y 


thanks_email 


Contents of thank you e-mail to 
be sent to payer 


2000 


Y 


Y 


N 


N 


thanksjmsg 


Thank you message from payee 
to payer after payment has been 
made 


120 


Y 


Y 


N 


N 


paycounter 


Type of payment counter, if any 


8 


Y 


Y 


N 


N 


PassThru 


Allow 1 -click payments from pay 
boxes 


Boolean 


Y 


Y 


N 


N 


thanks URL 


URL of thank you page 


120 


N 


Y 


N 


N 


CompanyName 


Name of Company 


40 


Y 


Y 


N 


N 


City 


City of organization 


40 


Y 


Y 


N 


N 
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Element 


Description 


Type or 


Display on 


Edit by 


Edit by 


Pass in 






Size 


Template 


Creator 


Payer 


URL 


State 


State of organization 


40 


Y 


Y 


N 


N 


page_searchable 


allow searching for this page 


Boolean 


Y 


Y 


N 


N 


transactiontype 


type of transaction 


8 


N 


N 


N 


N 


e-mail 


PayPage owner e-mail 


80 


N 


N 


N 


N 


name 


PayPage owner name 


80 


N 


N 


N 


N 


event_date 


Date of associated event 


date 


Y 


Y 


N 


N 


eventtime 


Time of associated event 


time 


Y 


Y 


N 


N 


labell-label6 


data field labels 


80 


Y 


Y 


N 


Y 


contentl- 


data field contents 


80 


Y 


Y 


Y 


Y 


content 6 














shipping 


shipping and handling amount 


6 


Y 


Y 


Y 


Y 


tax 


tax amount 


6 


Y 


Y 


Y 


Y 


SKU 


skuof item 


32 


Y 


Y 


N 


Y 


order number 


order number 


32 


Y 


Y 


N 


Y 


addrname 


name 


80 


Y 


Y 


Y 


N 


addr_line 1 


line 1 of address 


80 


Y 


Y 


Y 


N 


addrline 2 


line 2 of address 


80 


Y 


Y 


Y 


N 


addr_city 


city 


80 


Y 


Y 


Y 


N 


addr_state 


state 


80 


Y 


Y 


Y 


N 


addr_zip 


zip 


80 


Y 


Y 


Y 


N 


addr_country 


country 


80 


Y 


Y 


Y 


N 


charity 


PayPage is for a charitable 
purpose 


Boolean 


Y 


Y 


N 


N 


tipping 


Template supports tipping 


Boolean 


N 


N 


N 


N 


charity_ID 


ID of organization (if charity) 


20 


Y 


Y 


N 


N 


syndicate 


Allow page to be syndicated 


Boolean 


Y 


Y 


N 


N 


syndicate_fee 


Syndicate fee (commission) 


% 


Y 


Y 


N 


N 


provider- 


% of the syndicate fee that SP 


% 


N 


N 


N 


N 


syndicate_fee 


receives 













Table 1 



5 Some of the elements, such as the page title, amount, and description fields, are 

preferably required for all templates. Other elements may be selected at will by the 
template designer. 

The templates may also reference page handlers for performing specific actions. 
For example, the handler for a rebate template may extract the serial number of the 
10 purchased item and determine whether the number appears in a list of valid serial 

numbers. The handler could also update a database to mark this serial number as "used." 
In addition, the templates may include Javascript or other code for performing field 
validation, calculations, or other functions. 

For elements that can be passed by URL, a pay page's values may be overridden 
15 by parameter values contained within the URL (see block 92 of Figure 3). These 
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modified values may be specified by a pay box or other link to a pay page (e.g., an 
overriding suggested payment amount), or by advanced users. In a preferred embodiment, 
the parameters are passed as name-value pairs and can be passed in any order. For 
example, a URL specifying the amount, SKU, sale price, tax, and shipping for an item 
may be of the following form: 

http://www.sei^er.com/bob@antiques.com/?amount=20.00, sku=1234, tax=4.50, 
shippings. 50, itemprice=12.00 

V. Pay Boxes and SP-Generated Display Objects 

Each pay box preferably has a unique identifier that is assigned upon creation by 
the pay page owner. The identity of the corresponding pay page may be encoded within 
and determinable from this identifier. This identifier is preferably used by the image 
server 77 (Figure 2) to look up the associated pay box specifications from the content 
database. Some or all of the pay box's specifications, such as the style, color, and a pay 
page identifier, may alternatively be encoded within the pay box identifier. 

There preferably are two URLs associated with each pay box. The first URL is 
used to serve the pay box graphic, and may, for example, have the following form: 

http://www.server.com/payboxes/ {pay box ID}.gif 

The second URL points to the corresponding pay page, and is used to retrieve the pay 
page when a user clicks on the pay box graphic. This URL may, for example, have the 
following form: 

http://www.server.com/ {pay box ID} 

As mentioned above, one or more parameters (such as a suggested payment amount) may 
be passed with this second URL. The pay box ID is preferably included in the second 
URL to allow the application 76 to track click-through events on a per-pay-box basis. 
Requests for the pay box graphic may also be recorded to track the ratio of click-through 
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events to pay box impressions. As described below, historical data regarding impressions 
(i.e., viewing events), click-through rates, and success (payment) rates, may be provided 
to the pay page owners. 

For associate-hosted pay boxes, the URL formats are the same except that they 
include an identifier of the hosting associate. For example, the URLs may have the 
following formats: 

http://www.server.com/payboxes/{associate ID)/ {pay box ID}.gif 

http://www.server.com/ {associate ID}/{pay box ID} 

The associate ID is preferably recorded each time the associate-hosted pay box is 
requested, and each time the pay page is requested from that pay box. As discussed 
above, the pay pages application76 also uses the associate ID to credit an account of the 
referring associate when an associate-referred visitor makes a payment. 

As described above, the pay box URLs and associated HTML coding are 
generated automatically by the application 76 when a second party (owner) or third party 
(associate) selects a pay box to host (see Figures 10 and 16). Web site developers may 
alternatively install the pay boxes by manually generating the HTML or other coding. 

Figure 20 illustrates the general sequence of events that occur, in one embodiment, 
when a user (visitor) requests and views an external (2 nd or 3 rd party) web page containing 
a pay box. The drawing is also illustrative of the method used by the SP site to serve 
customized display objects other than pay box images. Initially, the visitor's browser 84 
transmits a request for the page to the 2 nd or 3 rd party site 120 (event 1). The site 120 
responds by returning the requested HTML document with the reference to (URL of) the 
pay box graphic (event 2). Upon parsing the HTML document and detecting this 
reference, the browser requests the pay box graphic from the SP site 66 (event 3). If the 
visitor is an existing user of the payment service, this request may include a cookie that 
can be used by the SP site to look up the name and 1 -Click settings of the visitor. 

The SP site 66 responds to this request by generating the pay box graphic (event 
4), as described with reference to Figure 3. As part of this process, the image server 77 
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looks up and/or decodes from the pay box ID the specifications of the pay box. These 
specifications may include, for example, the pay box size, color, message, and suggested 
payment amount specified by the pay page owner. In addition, if the request included a 
valid cookie, the image server 77 looks up the visitor's name and 1 -Click settings. The 
image server 77 uses the pay box specifications and visitor-specific information (if 
available) to generate the pay box graphic. As described above, the graphic may include 
the visitor's name, and may include a 1 -Click payment button 92F (Figure 4) if the 1- 
Click service is enabled. In one embodiment, payers may pre-specify the type or level of 
customization provided within pay box graphics (see section XIII titled "Payer 
Preferences for Treatment on External Sites"). 

The image server 77 could also include other types of personalized information 
within the graphic, or within another display object. For example, the graphic, or a 
separate dynamically-generated graphic, could be customized to include selected digits of 
the visitor's default credit card. In one embodiment, for example, the image server also 
generates and serves a separate bar which is displayed at the top of the same external web 
page. This bar preferably contains the name of the visitor (if recognized by the SP site), 
and information about payments made during the current browsing session. The bar may 
also include buttons for performing certain functions, such as negating the last payment, 
or adding an article being viewed to a personal library maintained by the SP. 

Further, the pay box graphic or other display object could include personal 
recommendations of products or services available for purchase from the SP. The 
personal recommendations may be generated based on user's purchase histories, browsing 
histories, and/or explicitly-specified interests, using methods that are well know in the art. 
These personal recommendations, and/or other display attributes of the graphic, could be 
selected based further on the identity of the hosting site 120. For example, if the hosting 
site 120 is an online sports shop and the visitor's profile indicates an interest in surfing, 
the graphic may list surf-related products sold by the SP. 

Further, rather than serving a customized graphic, the SP site could serve another type of 
object selected or customized based on the user's identity, such as a textual link or a 
streamed audio of video clip. It will also be recognized that the personalized graphic 
images or other display objects could be pre-generated (generated prior to being 
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requested), and/or cached following to dynamic generation, so that they need not be 
generated on-the-fly on each request. 

As further illustrated by Figure 20, the image server returns the dynamically 
generated pay box graphic to the browser (event 5), and the browser displays the graphic 
122 within the web page 124. Because the SP site serves the graphic directly to the 
visitor's browser, the personal information contained in the graphic is not exposed to the 
external web site or its operator. If the visitor subsequently selects the pay box (e.g., 
clicks on the graphic), the browser sends a request for the corresponding pay page to the 
SP site 66 (event 6). As described above, this request may include one or more pay page 
parameters. 

As will be appreciated from the foregoing, the method by which the SP site 
displays personalized graphics within external sites may be used for a variety of non- 
payment related applications (e.g., providing personal recommendations or links to related 
content). Further, the method may be used to serve personalized objects other than 
images. 

VI. Pay box Tracking and Feedback Reports 

The pay pages application 76 may provide periodic feedback reports to pay page 
owners and/or their associates. For owners, the feedback reports may include one or more 
of the following metrics, shown separately for each of the owner's pay boxes: (a) number 
of pay box impressions (viewing events), (b) number of pay box click-through events, (c) 
number of payments resulting from such click-through events, and (d) any resulting 
commissions. For pay page associates, the periodic feedback reports may include the 
same metrics (a)-(d), but the data would be provided separately for each pay box hosted 
by that associate. 

To generate the feedback reports, the pay pages application 76 preferably logs the 
following information each time a pay box is requested by a visitor's browser: (a) the pay 
box ID; (b) the associate ID, if any; (c) whether the visitor subsequently clicked through 
(selected) the pay box; (d) whether the click through event resulted in a payment to the 
pay page owner, (e) the amount of the payment, if any, (f) the amount of the associate 
commission, if any, (g) the identity of the visitor, if known, and (h) the date and time of 
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the visit. These and other types of information may be extracted from a server access log 
using well known methods. 

In addition to the information listed above, the owner may be provided with data 
regarding the number of associates that have signed up to host each pay box. 

VII. Controlled Access to Content Based on Payment History or Other User Attribute 
(Figure 2D 

The application 76 may also include functionality for rating payers according to 
their voluntary payment histories taken over some or all payees. This information may be 
used to allow pay page owners or other content providers to serve additional content (or 
take other actions) for "good" payers. For example, a musical artist could provide bonus 
tracks, or high quality MP3 files, to those having good payment histories. 

To generate the ratings, the application 76 may capture the following information 
for each payer: (1) number of pay pages viewed; (2) number of payments made; (3) 
payment amount compared to suggested amount (where payment is made); and (4) for the 
above data, the type of the pay page (charity, honor system, tipping, etc.). Using this data, 
the application may calculate the payer ratings based on one or more of the following 
metrics (and possibly additional metrics): (1) pay page views / payment %; (2) total 
amount paid / total amount suggested (for pages on which payment made); and (3) total 
amount paid / total suggested (for all pages viewed). The application may also track, and 
incorporate into the ratings, the number of times the payer viewed a pay box. In addition, 
the application may generate separate payer ratings for each of several pay page types. 

Any of a variety of methods may be used to allow the content provider to server 
ratings-based content to visitors. One such method involves the use of the SP site 66 to 
redirect the visitor to ratings-based destinations. With this method, the content provider 
initially sets up separate destinations (e.g., at respective URLs) for each of multiple payer 
rating categories, such as "poor," "average," and "good." For example, the content 
provider could post a sample version of a downloadable music title at the "poor" URL; a 
standard version of the title at the "average" URL; and an exclusive version of the title 
(e.g., with bonus tracks or in higher quality audio) at the "good" URL. URLs that are not 
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otherwise accessible from the content provider site (e.g., have no incoming or other links) 
may be used for this purpose. 

The content provider then accesses a "ratings-based content setup" area of the SP 
site 66 and specifies (1) the URLs of the destinations, and (2) messages to appear on 
5 corresponding graphics served by the image server 77. Continuing the example above, 

the messages may read as follows: 

Poor: "Click here to download a sample of Moby's latest single" 
Average: "Click here to download Moby's latest single" 
10 Good: "Click here to download Moby's latest CD" 

Each such message appears on a different version of a graphic served by the SP site 66. 
These graphics are preferably separate from the pay box graphics, although a pay box 
graphic could serve the dual role of providing payment functionality and access to content 

15 (e.g., via configurable "thank you page" URLs). The SP site may then generate the 

HTML or other code for installing the graphic within a web page (as in Figures 10 and 16 
above). As with pay boxes, another type of display object (animations, etc.) could be 
used instead of a graphic. 

Figure 21 illustrates the sequence of events that occur when a visitor accesses a 

20 page in which the graphic is installed. Initially, the visitor's browser 84 requests, and the 

content provider site 140 returns, the requested HTML document (events 1 and 2). The 
browser 84 then sends a request to the SP site 66 for the graphic referenced within this 
HTML document (event 3). If the visitor is a user of the payment service, this request 
may contain the visitor's cookie. In response to the request for the graphic, the SP site 66 

25 (image server 77) looks up the visitor's rating and selects the corresponding version of the 
graphic (event 4). If the visitor in unknown, or no rating exists for the visitor, a default 
version of the graphic may be selected. The selected graphic 142, which may be either 
pre-generated or generated dynamically, is then returned to the browser (event 5) and 
displayed within the web page. If the visitor subsequently clicks on this graphic 142, the 

30 browser sends a request for the content to the SP site 66, together with the visitor's cookie 

(event 6). The SP site responds to this request by looking up the user's rating and the 
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corresponding destination URL (event 7), and then redirecting the browser to this URL 
(events 8 and 9). One important aspect of this method is that the SP does not expose the 
visitor's identity or rating to the content provider site. 

The method illustrated in Figure 21 can be varied such that the SP site selects the 
5 destination URL based on some user attribute other than voluntary payment history. For 

example, the SP site could select the destination URL based on whether the user has 
purchased a particular item (e.g., users who bought a particular CD can access the bonus 
tracks associated with that CD, while other users can only access samples of such bonus 
tracks). Another example would be for the SP site to select the destination URL based on 
10 whether the user has purchased a subscription from the content provider. 

VIII. Payment-Based Access to Content 

The pay page and pay box features of the service may also be used to collect payments 
that are required before external content can be accessed. To provide such functionality, 
15 the payment service may support a protocol for notifying a content provider/payee when 

payment has been received. One example of such a protocol is as follows: 



1) Each content provider, when setting up a pay page, provides the SP with the 
content provider's public key and one or more destination URLs. Each destination 

20 URL may, for example, provide access to downloadable or viewable content. 

2) When a payment is made by a customer using that pay page (optionally using the 
single-action payment method described in section X), the amount of sale, the date 
& time, and/or other transaction information (e.g., e-mail address of customer, IP 
address of computer making request, etc.) are formatted into a string, and the sting 

25 is encrypted with the content provider's public key. 

3) The encrypted string is passed by the SP site as a parameter in the destination URL 
in a redirect message - initially to the visitor's browser and ultimately to the 
content provider site 140. The string may alternatively be transferred to the 
content provider site by another communications method. 

30 4 ) The content provider site decrypts the string and provides access to the customer 

according to the validity of the extracted information. The content provider may 
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prevent this string from being reused such that the URL serves as a one-time-use 
URL. The SP does not have to be involved or pass any more information to the 
content provider at this point. 



5 IX. Display of Payment Counter Data within Pay Pages 

As mentioned above, one feature that may be implemented by the service allows 
pay page owners to display real time payment counter data, such as a goal chart, within 
their pay pages. This feature may be enabled for certain types of pay pages (e.g., charity 
and honor system pages), and may be used to convey payment history data to pay page 

10 visitors. For example, a pay page for a charitable organization could display a chart 

showing the amount raised throughout a fundraising event; and a creator of a 
downloadable work could display the number of visitors who made honor system 
payments for the work. In both examples, the chart may be in the form of a goal chart 
showing the real time total relative to an owner-specified goal. The counter may be based 

15 on a particular pay page, or on a set of co-owned pay pages specified by the owner. 

In one implementation of the feature, the pay page owner is given the option to 
display a counter indicating (a) the number of payments received, (b) the total of such 
payments, or (c) both. In addition, the owner may be given the option to display this 
counter as a goal chart, in which case the owner is prompted to specify a goal value. 

20 Where a goal chart is used, the owner may also be able to specify whether payments 

should continue to be collected once the goal has been reached. Once a counter has been 
defined, the application 76 updates the counter as payments are received and displays the 
counter total within the pay page. The total may, for example, be displayed as a bar chart 
or thermometer showing the amount received relative to the goal 

i5 Any of a variety of other types of historical data could also be displayed within the 

pay pages. For example, the application could support the ability to display one or more 
of the following: average payment amount, percentage of visitors who make a payment, 
and average total commissions earned by associates of the pay page. 
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X. 1 -Click Payments from External Sites (Figure 22) 

Another feature that may be implemented by the service allows users to make 1- 
Click (single action) payments directly from externally-hosted pay boxes or other display 
objects (i.e., without viewing the corresponding pay pages during the payment process). 
To implement this feature, each pay page may be assigned a "PassThru" property 
indicating whether 1 -Click payments from pay boxes are enabled. The owner may be 
permitted to specify the page's PassThru setting during creation or editing of a pay page. 
For pass-through-enabled pay pages, the SP site 66 serves special 1 -Click pay boxes to 
recognized 1 -Click visitors. When a visitor selects a 1 -Click pay box, the SP site 
immediately redirects the user to the "thank you" URL pre-specified by the owner (or 
possibly the hosting associate). 

Figure 22 illustrates this process in further detail. It is assumed in the illustrated 
example that the user has the 1 -Click service turned ON, and that the pay page associated 
with the requested pay box is pass-through-enabled (has PassThru turned ON). Events 1- 
3 are the same as in Figure 20. In response to the request for the pay box graphic (event 
3), the SP site 66 determines that the visitor has the 1 -Click service turned ON and that the 
pay page is pass-through enabled. The SP site therefore generates and returns a special 1- 
Click version of the graphic (events 4 and 5). This graphic includes a 1 -Click button or 
message indicating that selection will complete the transaction. In addition, as described 
above, the pay box graphic displays the names of the visitor and the payee, and may 
include other information such as selected digits of the credit card number to be used for 
the transaction. 

Upon selection of the pay box graphic, the browser 84 transmits a request for the 
pay page together with the user's cookie (event 6). Because the cookie indicates that the 
user is a 1 -Click user, the site 66 responds to this request by (1) executing the transaction 
according to the visitor's 1-Click settings (event 7), and (2) redirecting the browser to the 
owner-specified "thank you" URL (event 8). This URL may, for example, be a page of 
the pay page owner's external web site. The visitor's browser could alternatively be 
redirected back to the external page from which the payment was initiated, in which case 
this page may then be displayed with an SP-served display object containing a payment 
confirmation message (e.g., "you just paid $1 to ContentProvider.com"). 
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Although a special 1 -Click version of the pay box graphic is preferably presented 
to recognized 1 -Click users (events 4 and 5 in Figure 22), a standard graphic or other link 
could alternatively be displayed to all users (e.g., a button which reads "click here to pay 
25 cents"). In such embodiments, the name of recognized visitors could optionally be 
5 displayed in some other display object served by the SP site (such as a bar at the top of the 

web page) for display within the same external web page. In addition, although the pay 
box graphics in the above examples include text indicating the payment amount, the 
payment amounts could be conveyed by another method. For example, green, blue and 
red payment buttons could represent payments of 5 cents, 10 cents, and 25 cents, 

10 respectively. Further, a given external web page could include multiple 1 -Click pay 
boxes (e.g., the three color-coded buttons mentioned above) to permit the visitor to select 
the payment amount. 

The method illustrated in Figure 22 and described above can also be used without 
requiring payees to have their own pay pages. For example, upon registering with the SP, 

15 the payee may be given a unique URL to be used for receiving payments from visitors to 

external (2 nd and/or 3 rd party) sites. This URL would take the place of the unique pay page 
URL. For recognized 1 -Click visitors, the process would be the same as shown in Figure 
22 and described above (i.e., the visitor would immediately be redirected to a thank you 
page, etc.). For visitors who are not recognized 1 -Click users, selection of the pay box 

20 would preferably cause the SP site to return a sign-in page. The user would then sign in 
(or register, if necessary), and then complete payment via a generic payment pipeline. 

It is also contemplated that the service could require that all payments made from 
external sites be made as 1 -Click payments (i.e., users would not be given the option to 
turn the 1 -Click service ON and OFF for purposes of making such payments). In such 

25 embodiments, all recognized visitors may be treated as 1 -Click users. 

XL Content Distribution Models 

As mentioned above, the SP site 66 may implement a service for hosting the 
downloadable content of pay page owners. The pay page owners may upload such 
30 content (optionally together with descriptive text) to a service provider database via a 

special area of the site. Where such a service is provided, the site may also include 
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functionality for users to search for downloadable content and make voluntary or required 
payments to the creators. For example, when the search engine returns a product detail 
page for a downloadable work, the detail page may automatically display the pay box of 
the creator. The SP site may also allow pay page owners to create links to their own 
5 content and embed these links within their own pay pages. For example, the pay page for 
a novelist may include links to each of his novels as hosted by the SP site. 

The SP site 66 may also provide a mechanism for web site operators to (1) locate 
the content uploaded by pay page owners (e.g., using a search engine), and (2) republish 
such content on their own web sites together with the pay boxes of the associated pay 

10 page owners. To participate in this program, web site operators may be required by online 
agreement not to republish any content without a corresponding pay box. Upon uploading 
new content to the SP database, the pay page owners may specify the commissions (if 
any) they wish to receive. 

The SP site 66 may also provide a mechanism for other users to locate the service- 

15 provider-hosted content of others, create links to such content, and embed these links 

within their own web sites. For example, an operator of a music site could search the SP 
database for music files, and incorporate links to such files (or to the pay pages of their 
creators) within the music site. As with associate-hosted pay boxes, these links may be 
generated automatically by the SP site, and may include an associate identifier that allows 

20 the SP to track and pay commissions for referrals. Whenever a visitor follows such a link, 
the site displays the content together with a pay box, pay page, or other entry point into 
the payment system. With this model, a user who hosts such a link may receive a 
commission whenever another user follows the link and makes a voluntary or required 
payment to the owner. 

25 

XII. Integration of Payment Service with External Content Provider Site 

Figure 23-25 are example screen displays illustrating how some of the above- 
described features may be used to allow users to make 1 -Click, honor system 
micropayments, and to access other SP services, from an external content provider site. In 
30 these examples, the service provider site is the Amazon.com web site. 
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Figure 23 illustrates an example, hypothetical web page of the external content 
provider site "Forbe.com." The external page includes two payment links 160 and 162, 
each of which is provided in association with a respective article. These links point to the 
SP site, and preferably to a pass-thru-enabled pay page ofForbe.com. 
5 Figure 24 illustrates a hypothetical page of the Forbe.com site displayed when a 

recognized 1 -Click user selects payment link 160 in Figure 23. As mentioned above, all 
visitors with service provider accounts could be treated as 1 -Click users for this purpose. 
In this example, the SP site responded to selection of the link by charging $.05 to the 
account of the visitor, FuMing Young, and by immediately redirecting the visitor to the 

10 page on which the article appears (the "story page"). The story page in this example 
includes a bar 166, and a discussion area box 168, which are dynamically generated and 
served by the service provider site according to the methods described above. The bar 
166 displays a payment confirmation message indicating that $.05 has been charged to the 
visitor's account. The bar 166 also includes buttons (links to the SP site) for (a) initiating 

15 a search, (b) viewing a listing of items commonly purchased by other users who paid for 

this article, and (c) viewing related products. The discussion area box 168 allows visitors 
to view and add comments about the article. Comments added via the discussion area 
object are stored within a database of the SP site. 

Figure 25 illustrates a story page according to another embodiment. In this 

20 embodiment, the bar 166 also includes an "unpay" button for negating the voluntary 
payment made for accessing the article. When this button 167 is selected, the SP site 
either (1) cancels the transaction if the payer's credit card has not yet been charged, or (2) 
refunds the transaction if the credit card has already been charged. The ability to negate 
or reverse payments in this manner may also be used in other contexts in which users 

25 make voluntary or honor system payments, such as those set forth above. In some 

embodiments of this feature, the payer can only negate the voluntary payment during a 
particular time duration following that payment. Each payee or content provider may be 
permitted to specify this time duration via the SP site - optionally separately for each of 
its pay pages. 

30 In addition, the bar 166 includes an "add to library" button for allowing the visitor 

to add the article to a personal library maintained on the service provider site. In this 
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example, the "discussion area" box 168 is a drop-down box shown in the dropped-down 
or "expanded" state. 

Figure 26 is an example page of the SP site describing how content providers can 
manually add HTML code around their links to "payment-enable" their content (i.e., add 
5 payment links of the type illustrated in Figure 23). This page also describes how the 
content provider can insert an optional discussion area box 168 within the same external 
web page as the payment link. 

Figures 27 illustrates a "paylink creation tool" form that may be provided on the 
SP site to automatically generate HTML or other coding for adding pay links. Once the 
10 user completes and submits the form (including specifying a nickname used for referral 
tracking), the SP site generates and returns the coding (Figure 28) to be inserted into the 
HTML document of the external web page. 

XIIL Paver Preferences for Treatment on External Sites 

15 The SP site 66 may also include functionality for payers to pre-specify how they 

should be treated by the SP when browsing external (second and/or third party) web sites 
that host pay boxes or other SP-customized content. For example, each payer may have 
the option, via an account setup area of the SP site, to specify one or more of the 
following preferences: (a) whether to be identified within pages of external web sites, (b) 

20 whether to be shown personal product/service recommendations within external web sites, 

(c) whether to be shown links to related sites, and/or related content, within external sites, 

(d) whether to be given access to payer-ratings-based content (see section VII above), (e) 
whether 1 -Click payments may be made from external sites, (f) whether to be shown a 
running total of payments made to the external site, and (g) whether to be notified when 

25 payments made to the external site reach a certain threshold. These and other preferences 

may be stored in the "user accounts" database 72 (Figure 2), and used by the SP site to 
customize pay box graphics and/or other content displayed within the external sites. The 
payer may also be given the option to set up one or more payment options for handling 1- 
Click or other payments made from external sites (e.g., all 1 -Click payments made on site 

30 A should be charged to credit card A, and all 1 -Click payments made on site B charged to 
credit card B). 
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Although the invention has been described in terms of certain preferred 
embodiments, other embodiments that are apparent to those of ordinary skill in the art, 
including embodiments which do not provide all of the features and advantages set forth 
herein, are also within the scope of this invention. Accordingly, the scope of the 
invention is defined by the appended claims. 
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